5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
- Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
+ Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 2-1: Data Dictionary Overview

File Storage Options


For each file you define in the data dictionary, APPX requests storage information. You determine whether each record format is stored in a file and, if so, whether the file is maintained on disk or in memory. The attributes of each of these file storage options are summarized in Table 2-1-3, and discussed in more detail in the following sections. 

Characteristic

Physical File

Disk File

Memory File

Permanent

Yes

Yes If So Specified

No

Capacity Limitation

Not Applicable

Amount of Disk

Paging Space

Shared Among Users

Yes

Yes (If Permanent)

No

Relative Performance

Not Applicable

Slower

Faster

Database Dependent

Yes

Yes (If Permanent)

No

Table 2-1-3. A Comparison of File Storage Types

An unstored record format is essentially a pseudo file that you can use to enter data, perform edit checks and computations, and execute statements without actually storing data. APPX does not read data into a record area before executing a process, and it does not store data after executing a process. In all other respects, record area operations are the same for unstored records as for records stored on disk or in memory.

There are two primary differences between unstored records and records stored in files (temporary or permanent). Unstored records:

Can only communicate data from one process to another by implicit or explicit interprocess communication, passing and receiving definitions. Unstored records communicate only through areas in memory. Records stored in temporary and permanent files are less restrictive. One process can write a record to a temporary file, and a separate process can read the record from the temporary file. Unlike information in unstored records, this information can be saved and retrieved at will.

Contain only the information that is in the current area in memory, which is the equivalent of a single record. Temporary and permanent files can contain more than a single record.

Unstored record formats are similar to work fields. You can think of a work field as an unstored record with a single field. Unlike work fields, however, unstored record formats:

Establish relationships between one field and another. As a result, they eliminate a number of the limitations that are inherent in work fields. You cannot include a work field in an APPX group field. You can define a group field that consists of fields from an unstored file, simplifying field manipulation and comparison in many instances. Without an unstored option, you could only compare records by reading a record from disk, loading each field on the record into a work field and, then, comparing each work field to a field in a second record. With the unstored option you can create a work record, containing all of the fields in a disk-based record and, using a group of the entire record, set the contents of the disk record into a work record with a single statement.

Can serve as process control files (PCFs) for APPX processes. If the record format includes a one-record organization specification, APPX completes one process cycle during process execution; in other words, APPX sequentially executes the frames for a process once and then ends. If the record format is other than one-record, the process continues to execute until the application user chooses to end it. For example, imagine a calculator utility that allows a user to enter principle and interest rate data and, then, computes and displays a monthly payment amount. If the unstored record format is one-record, the calculation is executed once and the program ends without saving the entered or calculated information. If the format is other than one-record, an application user can change the entered values as often as desired and APPX will continue to update the computation and the display until the user chooses to end.

Disk files are generally permanent files that are shareable among users and stored on a disk surface defined in file management. You can, however, define temporary files that are stored on disk.

The system always takes longer to retrieve data from files stored on disk than to retrieve data from files stored in memory. Disk files have an advantage over memory files because they have more capacity.

Permanent disk files are database-dependent, or stored as part of a specific database. As a result, APPX's database management utilities reference data dictionary specifications when operating on a disk file. Temporary disk files are database-independent.

Memory files are temporary files that are unique to a task. The contents of a memory file are lost when the task ends. Because files are maintained in memory and memory is relatively more expensive than disk space, the quantity of data in a memory file is generally limited. Excessive or improper use of memory files can result in memory overflow conditions.

The principle reason to use a memory file is to increase performance. The system always takes less time to retrieve data from files that are maintained in memory than to retrieve data from files that are stored on disk. By using memory files in strategic locations in a process, you enhance performance while maintaining your application as simply as possible. For example, assume you generate a report based on a 10,000-record customer file. For every customer record processed, APPX must also read a referenced record in a 10-record customer-type file. If the customer-type file is a disk-based file, APPX reads 20,000 records from disk, or a customer-type record for every one of the 10,000 customer records read. If, on the other hand, you read each of the 10 customer-type records into a memory file, your total number of physical I/Os is reduced from 20,000 to 10,001, which is a reduction of almost 50 percent.

 

Application Design Manual                                         "Powered by Appx Software"

128

©2006 By APPX Software, Inc. All Rights Reserved